library support for three ABIs: o32, N64, N32. O32 libraries
are located under /usr/lib. N64 libraries are located under
/usr/lib64. N32 libraries are located under /usr/lib32.
3.1.1.1 _O_3_2__A_B_I The o32 abi is essentially the same 32-bit
ABI supported by IRIX 5.3 with the following exceptions:
+o COFF is no longer supported.
+o The default Instruction Set Architecture (ISA) is now
MIPS2.
For the most part, IRIX 5.3 binaries will execute correctly
under IRIX 6.5 with the following exceptions:
+o nlist() will work on a 64-bit binary. nlist64() should
be used and is available to 32-bit programs.
+o Programs that read kernel structures through /dev/kmem
will have problems.
+o Programs that assume page sizes of 4k bytes may have
problems.
+o Programs compiled as COFF binaries with the IRIX 4
compatibility options.
3.1.1.2 _N_6_4__A_B_I The 64-bit (or N64) ABI was introduced on
IRIX 6.0 systems. It provides a 40 bit Virtual Address space
and supports the MIPS4 (default) and MIPS3 ISAs.
N64 implements a new calling convention which is
incompatible with the o32 calling convention. Under the
64-bit ABI the fundamental C language data types, long and
void* are 64-bits. As a result, porting applications from
o32 to N64 may require more effort than just recompiling the
source files.
- 2 -
For more information about N64, consult the MMMMIIIIPPPPSSSSpppprrrroooo 66664444----bbbbiiiitttt
PPPPoooorrrrttttiiiinnnngggg aaaannnndddd TTTTrrrraaaannnnssssiiiittttiiiioooonnnn GGGGuuuuiiiiddddeeee and abi(5) man page, which are
part of the compiler_dev product.
3.1.1.3 _N_3_2__A_B_I The new high performance 32-bit (N32) ABI
is being introduced in this release. It combines the calling
convention of the 64-bit ABI with the data type sizes of the
o32 ABI. As a result, porting applications from o32 to N32
should be easier than porting them to N64, but certain
caveats apply.
For more information, consult the MMMMIIIIPPPPSSSSpppprrrroooo NNNN33332222 AAAABBBBIIII GGGGuuuuiiiiddddeeee
which is part of the compiler_dev product.
Please note that each of the ABIs is not link compatible
with either of the other two ABIs. That is, you cannot link
objects of one ABI with objects or libraries of the other
ABIs.
3.1.1.4 _t_e_r_m_i_o__a_n_d__t_e_r_m_i_o_s__s_e_r_i_a_l__p_o_r_t__c_h_a_n_g_e_s The tttteeeerrrrmmmmiiiioooo
and tttteeeerrrrmmmmiiiioooossss structures have been changed to support bit
rates of greater than 38400 bps. Each of these structures
has two new members _c__o_s_p_e_e_d and _c__i_s_p_e_e_d which store the
output and input bit rates, respectively. They replace the
CCCCBBBBAAAAUUUUDDDD and CCCCIIIIBBBBAAAAUUUUDDDD fields of the _c__c_f_l_a_g member. CCCCBBBBAAAAUUUUDDDD and
CCCCIIIIBBBBAAAAUUUUDDDD should no longer be modified or examined by
applications. (Because no current SGI hardware supports
setting input and output to different rates, _c__i_s_p_e_e_d is
currently unsupported. Applications should either not
modify it, or should set it to the same value as _c__o_s_p_e_e_d.)
Unlike CCCCBBBBAAAAUUUUDDDD and CCCCIIIIBBBBAAAAUUUUDDDD, _c__o_s_p_e_e_d and _c__i_s_p_e_e_d encode bit
rates as plain integers. To set a bit rate of 38400 bits
per second, an application would set _c__o_s_p_e_e_d to the integer
value 38400. For convenience, macros such as BBBB33338888444400000000 have
been provided for several common bit rates. Note that the
capabilities of various serial port hardware differ; many
still do not support rates greater than 38400 bps (see
_s_e_r_i_a_l(7) for more information on different serial port
types.) Applications therefore need to check the return
values of library calls that attempt to set bit rates (such
as iiiiooooccccttttllll described here) , because the calls may now fail in
more situations than before.
For compatibility with existing binaries, MIPS ABI programs,
and programs that cannot be ported to use the new tttteeeerrrrmmmmiiiioooo or
tttteeeerrrrmmmmiiiioooossss structures, the old interfaces are retained.
Existing binaries automatically use the old interfaces. By
defining ____OOOOLLLLDDDD____TTTTEEEERRRRMMMMIIIIOOOOSSSS at compile time (before including
<<<<tttteeeerrrrmmmmiiiioooossss....hhhh>>>>, <<<<tttteeeerrrrmmmmiiiioooo....hhhh>>>>, or <<<<ssssyyyyssss////ttttttttyyyyddddeeeevvvv....hhhh>>>>), the old
- 3 -
interfaces are in effect. Please see the _t_e_r_m_i_o_s(7) man
page for more details on the new interfaces, and backward
compatibility.
Applications writers are strongly encouraged to use the
POSIX interfaces rather than these raw ioctl() interfaces